When updateOnPUT is set, then you need to change the HTTP path too, not only the verb.

updateOnPUT=false

  replaceById     => PUT /:id
  replaceOrCreate => PUT /

updateOnPUT=true

  replaceById     => POST /:id/replaceById
  replaceOrCreate => POST /replaceOrCreate

I don't think it's correct to call setRemoting twice for the same method, expecting it to create two HTTP endpoints. The correct way is to provide an array of values in the http property. See how exists defines two HTTP endpoints:

       http: [
         { verb: 'get', path: '/:id/exists' },
         { verb: 'head', path: '/:id' },
       ],

We should do the same here. For example:

var upsertEndpoints = [{ verb: 'patch', path: '/' }];
if (!options.replaceOnPUT) {
  upsertEndpoints.push( {
    verb: 'put',
    patch: '/',
  });
}

setRemoting('PersistedModel', 'upsert', {
  // ...
  http: upsertEndpoints
});

Or you can use the approach you have in place for replaceOrCreateOptions below, both ways are fine.

Perhaps this could be rewritten as follows?

options.replaceOnPUT = options.replaceOnPUT !== false;

What is the difference between this test and it('has expected remote methods with model.settings.replaceOnPUT set to true' above? I think it's enough to keep only one of these tests, isn't it?

Also please note I have changed the logic for formatMethod, getFormattedMethodsExcludingRelations, getFormattedScopeMethods,... based on the changes in strong-remoting...

I think the second item/alias should have prototype. prefix too.

 'prototype.patchAttributes', 'prototype.updateAttributes'

I think we either need to fix L627 to prepend prototype. prefix to isStatic:false methods, or change remoting definition of prototype.patchAttributes to specify method alias as prototype.updateAttributes. This depends on how strong-remoting treats aliases of prototype methods, which is something I am not sure about. Could you please check? It is also worth checking how loopback-connector-remote handles these aliases, to ensure code calling myModelInstance.updateAttributes keeps working (assuming the model is attached to a remote-backed datasource).